Network applications have evolved over time to take on a multi-tiered client and server arrangement (i.e., architecture). Typically, one or more server computers are connected through their network interfaces by one or more networks to one or more client computers. Networks may include data networks (e.g., Internet), voice networks (e.g., Public Switched Telephone Network—“PSTN”), wired or wireless networks, and any combination of these used to communicate data, voice, programs, general content, and/or other information. Networks may be local to a company or organization, such as a Local Area Network (“LAN”) and an intranet, or they may expand over large geographic areas, such as a Wide Area Network (“WAN”), that may even interconnect other networks. One widely used and developing network is the Internet, which includes the World Wide Web (“WWW”). The “WWW” uses Web browser software running on the client computers of the network to execute certain Web-based applications. These Web-based applications may include pages that are served from one or more of the Web servers on the WWW in HyperText Markup Language (“HTML”) format.
Many applications on the Internet, and other network environments, use a module or modules of software called “middleware”. Broadly, middleware can be any computer software function that is performed between a client and a host system such as a database server and a Web server. However, middleware typically runs on servers that operate between the clients and other servers in a network. For example, these other servers may include an Oracle® Database, IBM® DB2 and IBM® CICS server. Middleware is often used to execute certain computer programs which are meant to off load processing from these other servers, to preprocess information for client computers, and/or to perform a set of functions or services that are commonly needed for certain kinds of applications. Some examples of functions or services that are typically performed by “middleware” would be transaction monitoring and coordination, server load-balancing, host fail-over and other application level services.
A typical Enterprise Information System (“EIS”) is comprised of client computers, middleware servers, and database servers. Web servers are included within the EIS when Web browser based clients must be served via the Internet/Intranet. EIS's are generally known and may include application programs that perform the functions required by any given business and/or organization. For example, an EIS may include, inter alia: online customer order entry systems; online retail/wholesale sales, marketing, and inventory systems; enterprise supply chain management systems; product and/or content distribution systems (e.g. television, home video); online financial systems (e.g., mortgage applications, investing, stock trading, loan application, and credit card accounts); service providing systems (including medical, legal, real estate, engineering, education, distance leaning, and technical support); online human resource and payroll services; online banking systems (e.g., deployed by a bank or other financial institutions and/or the retail banking systems used internally by bank personnel); airline reservation systems; and any other general way of transacting business over a network.
Often these functions/application programs are made of parts. For example, an application program can be made of components, modules, or functions (see discussion of FIG. 1F below), which in turn are made of objects. The component, module or function may also include either an expressed or implied order in which to execute the respective objects in the component, module, or function. This order can be shown or defined by an execution graph. Restated, the execution graph may be implied by the “calling structure” of the program.
Execution of one or more of these components, modules, functions and/or entire applications can be performed at various locations over a network. This well known type of program execution is called distributed programming. One primary advantage of distributed programming is to more efficiently utilize the distributed computing resources over the network to achieve improved performance. Performance can be gauged using certain criteria such as execution time, and controlled using certain middleware applications such as fault-tolerance and load balancing. Important computing resources such as CPUs, network bandwidth, software functions and data storage must be well managed in order to achieve customary and generally known system requirements usually referred to as reliability, availability and scalability (“RAS”).
Distributed computing can allow programs to run faster because the work of the program is divided among multiple computer systems. Also, specific tasks in the program can be executed on a computer that has the facilities to best execute these tasks. For example, a mathematically intensive task could be run on a computer that has a particularly fast processor for executing mathematical problems and application programs that support a large variety of mathematical functions.
However, distributed programming often fails if the communication among the processors involved gets too complicated. Programs have to be developed and installed to insure that data among the processors is coherent. Some systems cannot tolerate noise or spurious signals on the network. Delays in receiving data from one or more processors could slow the entire system. In order to be distributed, application programs must be written so that tasks can be broken apart and the results of these tasks accurately combined. This often greatly adds to project development costs, assuming that these objectives can be accomplished at all. Communication between the various computers on the network and the programs/protocols the computers are using must be compatible.
Often the network is thought of as being divided into tiers where each of these components, modules, or functions is executed. These tiers are commonly divided by functional (or logical) and/or physical computing levels or sub-tiers. The advantage of dividing the network application system into multiple tiers is to facilitate the development and deployment of the various computing resources. Some times tiers are thought of as physical locations where components, modules, or functions of programs are executed. For example, some components, modules or functions can be executed on the EIS tier or middleware tier, while other components, modules, or functions are executed on the client computers (the client tier). Alternatively, tiers of the network can be divided logically, such as on a small human resource system, where the client and server part of the components, modules, or functions are all on one computer, but logically the components, modules, or functions are still developed and deployed based on the client and the server tier being separate tiers.
Network tiers can also be combinations of physical and logical tiers. For example, take an online banking system that is comprised of a client computer, middleware servers, and various backend database systems. Suppose the client, middleware and database systems are physically separate computer systems (tiers). The middleware tier may be subdivided into logical tiers such as a Web server, an application server, and a transaction server tier.
In much of the existing middleware, objects used are highly interdependent and defined by the function(s) of the middleware. Some well-known middleware objects include: Sun Microsystem's Java Server Page™ (“JSP”) and Enterprise Java Bean™ (“EJB”). The JSP object executes programs, based on requests from one or more clients. The EJB object executes certain programs that are pre-packaged into an “Enterprise Java Bean” format. Other objects may include, for example, general data files, general programs, and general multimedia content files (e.g., text, video, sound, and voice content).
It is often necessary for various servers and clients to communicate even though they may have different runtime environments (i.e., are running different application programs such as middleware) and are running on different platforms (i.e., have different hardware and operating systems). Generally, servers and clients communicate using well-known protocols like HyperText Transfer Protocol (“HTTP”) over TCP/IP. Other network communication protocols include Internet Interoperable Protocol (“IIOP”) that permits communication between different computer platforms over a network. One example of a technology that uses IIOP would be the Common Object Request Broker Architecture™ (“CORBA”). At a high-level CORBA specifies many standards involving application level communication among disparate applications and computing platforms.
The prior art discloses some “open” architectures that permit programmers to develop code that will have general use in a networking environment. Some of these architectures permit communication between programs executing on different systems, different platforms or environments, and even using different programming languages over the network (and network tiers.) An open architecture encourages development of applications that can be used generally with a flexibility to interact with any other architecture based program (component, module, function or object) without regard to what, where, or on what system the other application parts exist or execute.
One such open architecture system is called JINI™. JINI uses Java™ technology to wrap these otherwise incompatible programs, particularly driver programs for input/output devices so that these devices can be plugged into a JINI compatible network and operate and communicate with any other device on the network. For example, JINI can be used to permit any pervasive device on a wireless network to communicate with any other JINI compatible pervasive device that comes within the communication range of the wireless network.
FIGS. 1A–1E discussed below are each a block diagram illustrating a prior art middleware computer platform.
FIG. 1A is a block diagram illustrating a general middleware computer system 160 with well-known computer hardware 100, a general network operating system 102 (e.g., Microsoft Windows NT™), a middleware platform 104 (e.g., Microsoft® Commerce Server), a transactional operating system 106 (e.g., Microsoft® Transaction Server—“MTS”), and a given application program 108 (e.g., an online ticketing sales application).
FIG. 1B is a block diagram illustrating a generally known Java middleware platform 170 that has computer hardware 100 and a network operating system 102. A middleware platform which supports Enterprise Java Beans™ (“EJB”) 114 runs on the network operating system 102 that allows Java application programs 118 to run on the system 170.
FIG. 1C is a block diagram illustrating a generally known CORBA middleware platform 180 that has computer hardware 100 and a network operating system 102. The CORBA middleware platform 124 permits general application programs 120 to operate on this platform. For example, these application programs 120 may include Java™, C++, COBOL, and Smalltalk programs.
FIG. 1D is a block diagram illustrating a generally known Windows middleware system 190 that operates on Windows® compatible hardware 100. A Windows® DNS (COM/MTS) or MTS system is a middleware system 134 available from the Microsoft Corporation that permits general application program 120 to run on the platform 190.
FIG. 1E is a block diagram illustrating a generally known system 195 that uses hardware 100, a network operating system 102, and a middleware program 144 called TUXEDO™ (made by BEA Systems, Inc). This platform 195 runs application programs 146 written in the C programming language.
FIG. 1F is a diagram showing a prior art hierarchical relationship among system and application parts. The largest part is a system 105F that contain one or more complete applications 108. The system 105F also can contain one or more subsystems 106F that each in turn may include one or more applications 108. The application 108 is a group of one or more computer programs. Subapplications 110F are parts of applications 108. Some applications 108 and/or subapplications 110F may include one or more components 120F.
A component 120F may exist at a some significant layer within an application 108. A component 120F may be part of a distributed system that interacts with its environment by exchanging message/information with other components 120F and/or applications (108, 110F). Components 120F may include runnable (i.e., executable) and non-runnable parts. The runnable/executable parts of components 120F are generally called modules 130. Modules 130 in turn comprise one or more functions 140F also known as routines 140F or methods 140F.
Middleware, and for that matter, other prior art programs that function in a network environment, often need to communicate information between logical and/or physical functions in the network. For example, data or programs (e.g. objects) might need to be passed to a program or component, module, or function executing on the same machine as the application program. On the other hand, this information might have to be passed across the network to components, modules, functions, subapplications, or applications that are running on completely different computers. The prior art has various ways of addressing this problem. Some prior art passes information “by value” between components, modules, functions or applications. Thus, information needed is passed, e.g. in a “call statement” or header file to the component, module, function or application requiring the information. Other information, such as the results from a calculation, can be passed back in a same manner. Other prior art uses replication to pass information. In replication, programs and data are copied from one machine (computer) to a second machine where they are executed in an “island” mode.
Some prior art (e.g. Castanet™) is able to package and deploy business applications to computers over the network. Other prior art includes content distribution systems (e.g., those marketed by Akamai, Inc.) that physically locate caching servers throughout the world to cache content from Web sites and provide more local delivery to end user (clients). Similar systems include Digital Island, Ltd's global distribution network, called Footprint, that pushes certain application content through the network to servers located closer to the end-user. Inktomi Traffic Server™ is a network cache platform from Inktomi Inc. that delivers certain application content to servers across the network.
Several terms and concepts are defined in the prior art of software analysis, design, and programming languages. Software systems can be composed of one or more applications. These applications can be assembled from one or more components, modules, functions or objects.
In software written using object-oriented techniques, many modules further have a one-to-one correspondence with a class in the particular object-oriented language. A class or set of classes may also be considered a component if the class or set of classes meets the requirements of a specified component system. Examples of component systems are: COM, CORBA, EJB, ActiveX®, XPCOM, and Java Beans™.
Classes may be composed of one or more functions or procedures optionally coupled along with one or more variables. The functions or procedures are generally referred to as methods, while the variables are generally referred to as data members.
At runtime, classes are instantiated into objects, which are distinct entities, separate from the definition of the object, that is, the class. The data members represent the data or state of the object. The methods characterize the behavior of the object.
Build systems transform collections of non-runnable computer files into runnable computer modules and assembles them into components and applications. Build systems cannot identify or export required digital assets (hereinafter also termed assets) on an existing Enterprise Information System (“EIS”). Build systems also cannot identify runtime execution and data dependencies in previously installed EIS applications. Build systems generally contain incremental linkers which establish runtime relationships among modules of object code and are an improvement over regular linkers because they re-link only changed modules on command.
Archive utilities (e.g., archive utilities generating Zip, Gzip, and Tar archive files) are used for distributing and storing files. These files may contain one or more program and data files. Usually the archive files are compressed to save space. Archive files make it easy to group files and make transporting and copying these files faster. Typically, archive utilities examine the file types of the files to be zipped and invoke a file type specific compression subroutine to compress the file and add it to the archive.
Other types of software examine computer files and invoke rules based on file type to achieve specific results. Specifically, virus scan software will examine executable programs and based on one or more rules, determine whether there is a virus in the executable routine of the program. Virus scan software (e.g., McAfee virus software) can not be used and is not meant to be used to discover particular software, package the software, and then distribute the software over a network.
Software which may be classified as “enhanced” build systems (e.g., Starbase) control versioning of code and static elements of software products during development, as well as deployment of the completed products of development using various transport mechanisms to destination user computing platforms. Such enhanced build systems are designed to control and deploy only work in progress, ancillary products, and the completed products of development, and the inventory of code, static, and ancillary elements managed by such systems is rigorously constrained and must be rigorously constrained to those purposes. Such enhanced build systems cannot be used and are not meant to be used to discover particular software, package the software, and then distribute the software over the Internet.
The prior art also discloses specifications for deployment of Web components (particularly J2EE Web components), Enterprise Java Bean™ (“EJB”) components, and J2EE application data. The J2EE specification provides methods of transactional deployment of J2EE Web and EJB components to application server products that otherwise comply with the J2EE specification. There is no provision in the J2EE specification for transactional deployment of J2EE application data.
Using different computing environments and platforms creates many communication and operability problems on the network. For example, many computing environments (including middleware environments) only can operate with programs with which they are specifically designed to operate. Much of the prior art is unable to communicate or share information or programs with any general platform or computing environments. Much of the prior art cannot distribute programs and/or data over one or more networks so that the programs can be executed and the data used on any given platform or environment. Where this distribution occurs, it is only possible with the expenditure of considerable resources and highly trained system designers.
The prior art does not solve the need to be able to distribute data, programs, and portions of programs in a more efficient way over various tiers of a network to operate on any general platform or environment.
Another variation of this problem involves the explanation of middleware's intra-tier distribution versus inter-tier distribution. Middleware application servers are targeted at defining tiers of functionality. These tiers may scale within the tier, but not necessarily utilizing the processing power available in other tiers.
Much of the prior art middleware is constrained. Typically, middleware is only used with a particular EIS and is designed specifically for that EIS's platform and environment. Often this middleware operates in local area networks with 10/100 megabits of bandwidth or less. Most of this middleware cannot effectively function in a wide area network environment, or on the Internet, where bandwidth capabilities are often more restrictive. This middleware cannot communicate with computer systems that do not use the same communication protocols for which the middleware was designed.
Much of the middleware typically operates between the EIS Web server and the EIS database management system (“DBMS”). The result is that the performance of the middleware is limited by the performance of the EIS Web server and/or the EIS DBMS.
Much of the middleware does not work with components, modules or functions that are designed to execute on a platform/environment different than that of the EIS for which the middleware was designed. Therefore, this middleware can't organize, schedule, and/or distribute applications outside of the EIS. This prior art middleware cannot enable the execution of any general component, module, function, and/or application program to be executed on any general computer with any general platform/environment, nor does this middleware suggest how this might be done. The prior art middleware cannot distribute application programs and/or components, modules or functions for execution over different tiers of a network, nor has the prior art recognized the need to do this.
Some prior art architectures (e.g., JINI) permit communication between computers with different platforms/environments. However, much of this communication is used to enable standard interface functions like print, read data, etc. These architectures are not capable of decomposing complex application programs, of the sort found on an EIS, and recomposing these application programs so that they can be executed on any given platform. These prior art architectures cannot organize, schedule, and/or distribute application programs and/or components, modules, or functions across many tiers of a network so that these application programs/components, modules or functions can be executed on any general platform/environment.
Much of the prior art cannot automatically identify and extract subapplications, components, modules, functions, and specific files and data structures from legacy programs located on an EIS in order to export these application parts to other machines connected to the EIS through one or more networks. In addition, the prior art generally fails to identify these application parts by type so that the application parts can be processed in such a manner to include the necessary information and structures particular to the type so that the application part can be transformed and/or executed on various tiers of the network.